我应该多久创建一个类的新实例？
我不是一个“顽固”的程序员，我需要一些建议。
我正在开发一个网站，用户可以在其中搜索商店或品牌。
我创建了一个名为 Search 和 Store 的类。
有两种执行搜索的方式：“jQuery Live Search” 和“普通搜索”。
超过 2 个字符输入的每个字符都会触发实时搜索。因此，如果输入 5 个字符，则会执行 3 次搜索。如果您要查找的商店在下拉列表中，您可以单击该商店，然后将加载商店页面。
另一种搜索是输入 3 个或更多字符后单击搜索按钮。
每次执行搜索时，都会执行以下代码
$search = new Search();
$result = $search->search($_GET);
每次加载商店页面时，都会执行 $store = new Store()。
我的问题是这样的：
假设我有一个非常成功的网站，每小时大约有 100 个用户。每个用户至少搜索3次，浏览至少5家商店。
这意味着每小时创建 300 到 900 个搜索对象和 500 个存储对象。
创建这么多新对象是坏还是好？
我读过一些有关 Singleton 的内容，但有很多建议反对这一点。
我应该如何做到这一点才能获得最佳性能？我应该使用什么特定的设计模式？
I'm not a "die hard" coder and I need some advice.
I'm developing a website where users may search for a store or a brand.
I've created a class called Search and Store.
There are two ways search is executed: "jQuery Live Search" and "normal search".
Live search is triggered for each character entered above 2 characters. So if you enter 5 characters, a search is performed 3 times. If the store you are looking for is in the dropdown list, you can click the store and the store page will be loaded.
The other search is when you click the search button after entering 3 or more characters.
Every time a search is performed, the following code is executed
$search = new Search();
$result = $search->search($_GET);
Each time a store page is loaded a $store = new Store() is executed.
My question is this:
Let's assume I get a very successful website and I have aroun 100 users per hour. Each user searches at least 3 times and looks at least 5 stores.
That means between 300 and 900 search objects are created every hour and 500 store objects.
Is it bad or good to create so many new objects?
I've read a bit about Singleton, but many advices against this.
How should I do this to achieve best performance? Any specific design pattern I should use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不认为创建类会成为您网站的瓶颈。查看像 Zend Framework 这样的 MVC 框架，并检查每次调用生成了多少个类实例。创建类实例的开销几乎为零，搜索会给您的数据库带来热量（假设您使用的是像 mysql 这样的数据库）。
我建议在 jQuery Live 搜索中使用计时器，以便在用户停止输入更多字符后进行搜索。就像每次输入字符时刷新计时器一样，当计时器触发时，您实际上可以进行搜索。
我认为更大的问题之一是你的数据库。如果您有很多读取请求，像 memcache 这样的良好缓存层可能会从数据库中承担大量负载。
优化数据库的搜索应该是保持高性能的一个很好的措施。为了充分利用您正在使用的数据库，需要遵循许多调整和最佳实践。
作为 prodigitalson 的评论，建议使用 Lucene 进行全文搜索甚至可能比调整数据库更有效。
如果 Lucene 对您来说有点开销，您可能需要查看 Zend_Search_Lucene< /a> 组件，它执行相同的工作并且是用 php 编写的。
I don't think that creating the classes will become a bottleneck for your site. Look at an MVC Framework like Zend Framework, and examine how many instances of classes are generated for every call. The overhead of creating an instance of a class is almost nothing, the search will put heat on your db(assuming you are using a db like mysql).
I suggest using a timer for your jQuery Live search to do the search after the user stopped entering more characters. Like refreshing everytime the timer when a character has been entered and when the timer fires you can actually search.
I think one of the bigger problems will be your database. If you have many reading requests a good caching layer like memcache may take a good heap of load from you DB.
Optimizing your db for searches should be a good measure to hold performance high. There are many tweaks and best practices to follow to get the most out of the db you are using.
As a comment of prodigitalson suggested diving into full text search with Lucene could even be more efficient than tuning the db.
If Lucene is bit overhead for you, you may want to look at the Zend_Search_Lucene component, which does the same job and is written in php.
不要通过猜测性能瓶颈来使您的设计过于复杂。创建的对象数量很少会成为问题。
如果您需要稍后进行优化，memcached 层可以帮助您。
Don't overcomplicate your design by guessing at performance bottlenecks. Number of objects created would rarely be an issue.
If you need to optimize at a later point, a memcached layer could help you.
即使您必须稍微注意这些对象的尺寸，创建大量对象也不应该成为应用程序中的性能问题。
不要让你的设计过于复杂，但我认为单例模式并不复杂，而且实现起来并不困难。
因此，如果同一个对象实例可以在同一用户（甚至不同用户，如果在应用程序逻辑中可能的话）的不同搜索中重复使用多次，那么不要害怕使用单例。它可以节省您的内存，并防止您犯与执行相同任务的多个对象实例相关的错误，最终共享资源。
Creating an high number of objects shouldn't be a performance problem in your application even if you have to pay a bit of attention to the dimensions of these objects.
Don't complicate too much your design, but i think that singleton pattern isn't a complication and it isn't difficult to implement.
So if the same object instance can be reused more times upon different search from the same user (or even by different users, if it is possible inside your application logic), then don't be afraid of using singleton. It saves your memory and preserves you from doing errors related of having multiple instance of objects that performs the same task, eventually sharing resources.