Comments (9)
I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.
-edit-
Corrected the if ($count > 0) check in foreach loop, which improved loadtime a bit.
Problem is also the amount of data we need to download from Twitter. And that filtering occurs after downloading. Don't know if we can optimize that much.
from tweet-display-back.
Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too different.
On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:
I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
0
from tweet-display-back.
Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.
We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.
Op 27-6-2011 21:51, mbabker schreef:
Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too different.On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
0
from tweet-display-back.
Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything we
can to optimize the code, we should be OK.
On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:
Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.Op 27-6-2011 21:51, mbabker schreef:
Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
22
0Reply to this email directly or view it on GitHub:
#2 (comment)
8
from tweet-display-back.
Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)
Op 27-6-2011 22:00, mbabker schreef:
Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything we
can to optimize the code, we should be OK.On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.Op 27-6-2011 21:51, mbabker schreef:
Definitely the module once we start pulling too many tweets. Part of it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
220
Reply to this email directly or view it on GitHub:
#2 (comment)
8
from tweet-display-back.
I have the option to turn caching on and off in the module params. I
could force it to always cache and just leave the option to set the cache
life, but I don't think that's too user friendly.
On 6/28/11 12:36 AM, "Twentronix"
[email protected]
wrote:
Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)Op 27-6-2011 22:00, mbabker schreef:
Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything
we
can to optimize the code, we should be OK.On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.Op 27-6-2011 21:51, mbabker schreef:
Definitely the module once we start pulling too many tweets. Part of
it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as
a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
48
220
Reply to this email directly or view it on GitHub:
#2 (comment)
99
8Reply to this email directly or view it on GitHub:
#2 (comment)
8
from tweet-display-back.
Okay I see. But if it is neccesarily, that is maybe better then to
always turn it on. And maybe it is more user friendlier (one option less
that could be setup wrong). What would be negative side effects? Dunno
what's best to do. I'll leave that to you I think ;)
Met vriendelijke groet,
Jurian Even
Op 27-6-2011 22:09, mbabker schreef:
I have the option to turn caching on and off in the module params. I
could force it to always cache and just leave the option to set the cache
life, but I don't think that's too user friendly.On 6/28/11 12:36 AM, "Twentronix"
[email protected]
wrote:Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)Op 27-6-2011 22:00, mbabker schreef:
Caching is a must, otherwise you burn through the 150 pull requests per
hour very quickly. At the end of the day, so long as we do everything
we
can to optimize the code, we should be OK.On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we could,
it would be nice to make it quicker yes.Op 27-6-2011 21:51, mbabker schreef:
Definitely the module once we start pulling too many tweets. Part of
it
is inevitably going to come down to the connection from the server and
how
long it takes to query the data. I'm using 25 tweets on localhost as
a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
48
220
Reply to this email directly or view it on GitHub:
#2 (comment)
998
Reply to this email directly or view it on GitHub:
#2 (comment)
8
from tweet-display-back.
As many e-mails as I get about people getting the "you've reached the
limit" message, maybe it would be a better idea to force caching. I'll
solicit some feedback off the dev releases and figure something out before
2.0 is called a beta release.
On 6/28/11 1:00 AM, "Twentronix"
[email protected]
wrote:
Okay I see. But if it is neccesarily, that is maybe better then to
always turn it on. And maybe it is more user friendlier (one option less
that could be setup wrong). What would be negative side effects? Dunno
what's best to do. I'll leave that to you I think ;)Met vriendelijke groet,
Jurian EvenOp 27-6-2011 22:09, mbabker schreef:
I have the option to turn caching on and off in the module params. I
could force it to always cache and just leave the option to set the
cache
life, but I don't think that's too user friendly.On 6/28/11 12:36 AM, "Twentronix"
[email protected]
wrote:Ok, yes good point @150!
Maybe we could implement caching on a way it automatically cache. Or
maybe you already did some :)Op 27-6-2011 22:00, mbabker schreef:
Caching is a must, otherwise you burn through the 150 pull requests
per
hour very quickly. At the end of the day, so long as we do everything
we
can to optimize the code, we should be OK.On 6/28/11 12:25 AM, "Twentronix"
[email protected]
wrote:Yes true,
mind that the most stress test will be all the filters on:
filter @mentions, filter @reply and don't show retweets.We could at least instruct users to cache the module, but that's not
really nice and not adressing the real problem of course. If we
could,
it would be nice to make it quicker yes.Op 27-6-2011 21:51, mbabker schreef:
Definitely the module once we start pulling too many tweets. Part
of
it
is inevitably going to come down to the connection from the server
and
how
long it takes to query the data. I'm using 25 tweets on localhost
as
a
stress test, but I bet if it was only 3-5 tweets the time difference
between the 1.5.5/1.6.5 release and current code wouldn't be too
different.On 6/27/11 8:17 PM, "Twentronix"
[email protected]
wrote:I thought it was my localhost website, so it's the module...
Maybe it's looping somewhere too much in the code.Reply to this email directly or view it on GitHub:
#2 (comment)
14
48
220
Reply to this email directly or view it on GitHub:
#2 (comment)
49
998
Reply to this email directly or view it on GitHub:
#2 (comment)
06
8Reply to this email directly or view it on GitHub:
#2 (comment)
4
from tweet-display-back.
In commit 938c7bc, I added an additional check to see if filtering was even active on mentions and replies, and if it wasn't, I just fed the data straight into processItem. I also moved the feeds check to before the filtering code. This should help slightly for those instances. I'm not quite sure there's much else that can be done at this point.
from tweet-display-back.
Related Issues (20)
- fsockopen() error HOT 2
- Parameter: N. of tweets
- Language problems HOT 2
- How do I style this in joomla 3? HOT 1
- E-mail Test HOT 1
- NOTICE - Extension Discontinuation
- No new tweets being displayed HOT 5
- PHP Fatal error - Tweet-Display-Back HOT 4
- CSS and button HOT 1
- Double tweets HOT 32
- Security HOT 1
- W3C Validation HOT 7
- Show Retweets set to NO but retweets are displayed HOT 1
- customazing date format HOT 3
- Due to an error, potentially a timed-out connection to Twitter HOT 15
- Double Tweets - 3.1.0 Beta HOT 9
- Truncated Retweets
- Duplicate Tweets 3.1.0 HOT 1
- Tweets not showing on the module HOT 6
- Error 0 : Could not retrieve bearer token (consumer) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tweet-display-back.